1. Field of the Invention
The invention relates to programmable integrated circuits (ICs). More particularly, the invention relates to parametric logic modules for implementing designs in programmable ICs, and software tools and methods for creating such modules.
2. Description of the Background Art
Programmable ICs are a well-known type of digital integrated circuit that may be programmed by a user to perform specified logic functions. One type of programmable IC, the field programmable gate array (FPGA), typically includes an array of configurable logic blocks (CLBs) surrounded by a ring of programmable input/output blocks (IOBs). The CLBs and IOBs are interconnected by a programmable interconnect structure. The CLBS, IOBS, and interconnect structure are typically programmed by loading a stream of configuration data (bitstream) into internal configuration memory cells that define how the CLBS, IOBS, and interconnect structure are configured. The configuration data may be read from memory (e.g., an external PROM) or written into the FPGA by an external device. The collective states of the individual memory cells then determine the function of the FPGA.
One such FPGA, the Xilinx XC4000.TM. Series FPGA, is described in detail in pages 4-5 through 4-78 of the Xilinx 1996 Data Book entitled "The Programmable Logic Data Book" (hereinafter referred to as -the Xilinx Data Book"), published September, 1996, available from Xilinx, Inc., 2100 Logic Drive, San Jose, Calif. 95124, which pages are incorporated herein by reference. (Xilinx, Inc., owner of the copyright, has no objection to copying these and other pages referenced herein but otherwise reserves all copyright rights whatsoever.)
As FPGA designs increase in complexity, they reach a point at which the designer cannot deal with the entire design at the gate level. Where once a typical FPGA design comprised perhaps 5,000 gates, FPGA designs with 20,000 gates are now common, and FPGAs supporting over 100,000 gates will soon be available. To deal with this complexity, circuits are typically partitioned into smaller circuits that are more easily handled. Often, these smaller circuits are divided into yet smaller circuits, imposing on the design a multi-level hierarchy of logical blocks. The imposition of hierarchy makes it possible to implement designs of a size and complexity that would otherwise be unmanageable.
True hierarchical design is difficult to achieve for FPGAs using currently-available software. Designs can be entered hierarchically (e.g., via schematic entry or Hardware Description Languages (HDLs)), but mapping, placement and routing software typically "flattens" the design. It is desirable to retain the hierarchy as long as possible through the mapping, placement, and routing stages of implementing the design. The advantages of maintaining a hierarchy include faster software (because fewer objects at a time require manipulation), ease of changing the design (because only a discrete portion of the total logic has to be changed), and ease of doing incremental design (retaining a portion of a design while remapping, replacing, and rerouting only the part of the design that has been changed).
One result of the "hierarchical advantage" is the development of "module libraries", libraries of predeveloped blocks of logic that can be included in a hierarchy of logical blocks. A higher-level block incorporating (instantiating) a second module is called a "parent" of the instantiated module. The instantiated module is called a sub-module or "child" of the parent. Such library modules include, for example, adders, multipliers, filters, and other arithmetic and DSP functions from which complex designs can be readily constructed. The use of predeveloped logic blocks permits faster design cycles by eliminating the redesign of duplicated circuits. Further, such blocks are typically well tested, thereby making it easier to develop a reliable complex design.
To offer the best possible performance, some library modules have a fixed size and shape with relative location restrictions on each element. One such module type (now obsolete) was the "hard macro" from Xilinx, Inc. Hard macros are described in the "XC4000 Family Hard Macro Style Guide", published Sep. 3, 1991 and available from Xilinx, Inc., which is incorporated herein by reference in its entirety. A hard macro did not require schematics; instead, it included a schematic symbol that was used to include the macro in a customer design, and a netlist referenced by the schematic symbol and representing the macro circuitry. The netlist was encrypted and sent to customers in binary format, which made it difficult to edit or reverse-engineer the netlist. (A "netlisto is a description of a circuit comprising a list of lower-level circuit elements or gates and the connections (nets) between the to outputs and inputs thereof.)
One disadvantage of the hard macro format was that the area of the FPGA encompassed by the hard macro was totally dedicated to the contents of the macro. A customer could not place additional logic in a CLB within the area, or access any signal inside the area unless the signal had an output port defined as part of the hard macro. Further, the area of the FPGA encompassed by the hard macro had to be rectangular. If the logic fit best, or resulted in the fastest performance, in a non-rectangular area, the extra CLBs required to make the area rectangular were wasted. Hard macros did not include routing information.
Another type of module having a fixed size and shape is the Relationally Placed Macro (RPM) from Xilinx, Inc. RPMs are described in pages 4-96 and 4-97 of the "Libraries Guide" (hereinafter referred to as the "Xilinx Libraries Guide"), published October 1995 and available from Xilinx, Inc., which pages are incorporated herein by reference. An RPM is a schematic that includes constraints defining the order and structure of the underlying circuits. The location of each element within the RPM is defined relative to other elements in the RPM, regardless of the eventual placement of the RPM in the overall design. For example, an RPM might contain 8 flip-flops constrained to be placed into four CLBs in a vertical column. The column of four CLBs can then be placed anywhere in the FPGA.
Relative CLB locations within an RPM are specified using a Relative Location Constraint called "RLOC". RLOC constraints are described in detail in pages 4-71 through 4-95 of the Xilinx Libraries Guide, which pages are incorporated herein by MEi reference. Elements having an RLOC value of R0C0 are located in a given CLB corresponding to the (0,0) coordinate location. The next CLB "below" the (0,O) CLB is designated as R1C0, corresponding to the (0,1) coordinate location. Although the iA RPM has a rigid size and shape, other logic can be placed within the borders of the RPM. RPMs, like hard macros, do not include routing information.
A hard macro or RPM implementation of a logic module represents a single fixed circuit targeting a specific FPGA architecture. To accommodate even a slight difference in logic or a different FPGA architecture, a new RPM must be created. Therefore, libraries of RPMs are typically large and limited in scope.
Some flexibility has been provided by creating a different type of library module called a parametric module (i.e., a module having one or more associated variable values). One such type of parametric module is described in pages 1-1 to 2-14 of the UX-BLOX User Guide", published April, 1994 and available from Xilinx, Inc., (hereinafter the "X-BLOX User Guide"), which pages are incorporated herein by reference. The X-BLOX.TM. software tool includes a collection of library modules from Xilinx, Inc. X-BLOX modules comprise schematic symbols that can be added to a schematic representation of an FPGA design, and then parameterized to specify such variables as bit width, initial values, and so forth. The schematic including one or more X-BLOX modules is then translated into a netlist, and the netlist includes instantiations of the X-BLOX modules. Translation software then implements the X-BLOX module as lower-level circuit elements targeted for the Xilinx XC4000 Series FPGA, and includes these elements in the netlist. The netlist is then implemented in the FPGA by standard mapping, placement, and routing software which generates a configuration bitstream.
X-BLOX modules, although customizable, have a predefined shape and size based on the user-defined parameter values. For example, a counter module (called "COUNTER") is typically implemented as a column of CLBS, wherein the number of CLBs involved is dependent on the value of the parameter "COUNT_TO" (which defines the maximum value of the counter). The COUNTER module is described on pages 4-36 to 4-46 of the X-BLOX User Guide, which pages are incorporated herein by reference. While the size of the counter varies according to the value of the parameter COUNT_TO, for a given parameter value the X-BLOX module has a fixed size and shape.
A newer generation of the X-BLOX product is the LogiBLOX.TM. tool, also from Xilinx, Inc. A LogiBLOX module has similar capabilities to an X-BLOX module with some accompanying advantages, such as the availability of different logical implementations for a single module. For example, by setting a parameter in a graphical user interface, a user can specify that a multiplexer be implemented using tristate buffers driving horizontal interconnect lines, rather than using the default CLB implementation. The LogiBLOX product is described on pages 4-3 and 4-4 of the "CORE Solutions Data Book", copyright 1997, and available from Xilinx, Inc., (hereinafter the "CORE Solutions Data Book"), which pages are incorporated herein by reference.
Another product comprising parametric modules is the LogiCORE.TM. library and software tool from Xilinx, Inc., which is described on pages 2-3 to 2-4 of the CORE Solutions Data Book, which pages are incorporated herein by reference. One LogiCORE product is the LogiCORE PCI interface module, described on pages 2-5 to 2-20 of the CORE Solutions Data Book, which pages are incorporated herein by reference. The LogiCORE PCI interface product includes a graphical user interface which allows the user to customize a "header" portion of the PCI design. The data entered by the user comprises memory initialization data that is stored in a predefined register portion of the PCI interface design. The data does not otherwise alter the logic of the PCI interface circuit implemented by the module, other hi than to adapt the module to the target application.
Another LogiCORE product is a set of DSP CORE modules, described on pages 2-21 through 2-91 of the CORE Solutions Data Book, which pages are incorporated herein by reference. The DSP CORE modules are parameterizable VHDL modules. (VHDL is one well-known type of HDL.)
Another parameterizable logic block is described by Karchmer et al in UK Patent Publication GB 2306728 A, published May 7, 1997, entitled "Programaable Logic Array Design Using Parameterized Logic-Modules" (hereinafter "Karchmer"), which is incorporated herein by reference. Karchmer describes a programmable logic module in which parameter values are passed down through a module hierarchy from a parent module to child modules placed within the parent.
It is clear that X-BLOX, LogiBLOX, and LogiCORE modules are optimized as independent blocks of logic, not in the context of the entire design. It would be desirable for library modules to be implemented in a manner leading to the optimal complete design, rather than to a conglomeration of separately optimized circuits.
Morphologic, Inc., of Bedford, N.H., reports that they have devised a type of library module which is implemented based on both user-supplied parameters (including bit widths, setup time, clock to Q time, known sizes, shapes, and latencies) and dynamically generated parameters. These dynamically generated parameters include the target FPGA architecture and the type of tile (e.g., CLB or IOB) present in the portion of the FPGA to be occupied by the logic in the module. For example, when a Morphologic register module is targeted, using the Morphologic Floorplanner tool, to a Xilinx XC4000 Series FPGA, the module may be implemented in either a CLB or an IOB. When the Morphologic module is moved within the interactive floorplanner from a CLB area to an IOB area, the register is implemented using IOB input flip-flops rather than CLB memory elements. When moved from one FPGA to another, and the FPGAs have different architectures (for example, the module is moved from a Lucent Technologies ORCA FPGA to a Xilinx XC4000 Series FPGA) the Morphologic module reportedly changes from an implementation directed to the first FPGA architecture to another implementation directed to the second FPGA architecture. When moved from place to place on a single FPGA within the Morphologic floorplanner, the Morphologic module can reportedly change its shape by rearranging sub-modules within the module, if in the new location it would overlap with a previously placed module.
Although a Morphologic module can reportedly adapt to the location in which it is placed during an interactive (i.e., manual) floorplanning step, it would also be desirable to have the ability to optimize a module not only in the context of the shapes of neighboring modules, but also based on the logical interconnections that must be formed between modules. It would be further desirable to have the ability to adapt the shape of a module at the time the design is mapped, placed, and routed, rather than adapting the shape at an earlier time (e.g., in the Morphologic interactive floorplanner or using other prior art methods) and then "freezing" the module so that it is unable to respond to later changes. It would further be desirable to be able to adapt not just the physical structure (the shape), or the target FPGA architecture, but also the logical structure (the way the circuit is logically implemented) in response to the requirements of other modules.
When hierarchy is imposed using hard macros or RPMs, locally optimized solutions are created, because placement of elements within modules is without reference to spatial or timing requirements of neighboring modules. Therefore, it would be desirable to have the ability to alter a module at the time the design is mapped, placed, and routed, based on the various requirements of the complete design.